The Open Systems Interconnection (“OSI”) Basic Reference Model is a layered, abstract description for communication systems and computer networks as shown in FIG. 1. Many communication systems are normally designed according to the OSI layered model. A layer is a collection of related functions that provides services to the layer above it and receives services from the layer below it. In a layered model of a communication system, there are different processing entities in each layer at both ends of a communication system.
A processing entity in each layer at one end of a communication system normally communicates with a processing entity at the same layer at the other end of the communication system. The processing entities at the same hierarchical layer at any two ends of a communication system, referred as peers, is illustrated in FIG. 1. For example the Physical layer at one end of the communication system is peer to the Physical layer at the other end of the communication system as illustrated in FIG. 1.
There may be different communication protocols defined for each layer. The peers at each layer communicate with each other using these protocols. Also each peer entity normally communicates with the processing entities in the layer above it and the layer below it. The unit of data exchanged at a given layer is referred as a Protocol Data Unit (“PDU”). The names of the PDUs at different layers may be different in different communication systems. For example, a PDU at Network layer is referred as an N-PDU and a PDU at Transport later is referred as a T-PDU.
A protocol entity in one layer may often format the PDUs received from its adjacent layers into a structure that is more suitable for further processing in its own layer. A typical PDU may have two kinds of information, namely control information and user data. Often, user data is also referred to as payload data.
The control information contains necessary details that describe the rest of the PDU. For example, the control information may include source and destination addresses, error detection codes such as Cyclic Redundancy Check (“CRC”), length of the PDU, sequencing information, etc. The control information is generally located at the beginning of a PDU. There may also be some control information such as CRC, message authentication codes, etc. located at the end of a PDU. The control information that is located at the beginning of a PDU is often referred as “Header.” The control information that is located at the end of the PDU is often referred as “Trailer.”
Normally the control information and the payload data are collectively called as a PDU for a particular layer. Some PDUs may contain both a Header and a Trailer for control information while some PDUs may contain only a Header for control information. The presence of a Trailer may be negotiated by two peer protocol entities or may be indicated by the PDU Header. The generic structure of a PDU with Header, Trailer and the payload data is illustrated in FIG. 2. Normally the control information added to the payload data by one protocol layer is treated as payload data by a protocol layer below it, as illustrated in FIG. 3.
Often the formatting of data by a protocol entity includes fragmentation, reassembly, and concatenation operations as shown in FIG. 4. These types of operations are required for variety of reasons including the maximum PDU size limitation of some networks, different payload data being multiplexed over a physical communication medium, different preferred PDU sizes for different applications, etc. For example, real-time applications such as Voice over Internet Protocol (“VoIP”) may prefer smaller PDU sizes whereas non real-time applications such as file transfer may prefer larger PDU sizes. Furthermore, the physical layer protocol entity which communicates over the physical medium may use the PDU sizes that are optimal for communication over the particular physical medium of the communication system. For example if the communication medium is wireless, normally the PDU sizes may be small.
The concatenation operation at the transmitter groups a number of PDUs in a single unit of data for further processing. This single unit of data that includes one or more PDUs is referred herein as a “burst” as shown in FIG. 5. Note that some PDUs in a burst may have both a Header and a Trailer while others may have only the Header depending on the actual protocol being used by peer entities and different types of payload data. At the receiver, the corresponding peer protocol entities accept a burst of data that contains one or more PDUs, checks the control information in the PDU Header and unpacks the individual PDUs from the received burst.
Often there are errors introduced along the communication path as the data travels from one end to the other end. Some of these errors may be corrected by error correcting codes that may be typically used by the Physical layer entity of the communication system. However, the error correcting codes used at the Physical layer entity may not be able to detect and/or correct some of the errors. The protocol entities above the Physical layer entity may need to detect errors that are not corrected by the Physical layer entity. A commonly used technique for detecting uncorrected errors is the CRC. Often a CRC is included along with other control information in a PDU. The corresponding peer entity at the receiver checks this control information in the PDU and determines whether the PDU is error free and then takes appropriate action.
Since the PDU Header contains critical control information that describes the rest of the PDU, it is important to ensure the correctness of the PDU Header. For this purpose, some communication systems compute and insert a separate CRC specifically for the PDU Header and append it as part of the PDU Header as shown in FIG. 6. The CRC for the PDU Header is referred to herein as a Header Check Sequence (“HCS”). Often the length of the PDU Header for protocols at some layers is fixed and it may be known a priori. Normally, the receiver of the communication system uses the HCS that is included in the PDU Header to determine its correctness. If the HCS computed by the receiver matches with the received HCS, then the PDU Header may be considered valid otherwise it may be considered invalid. If the PDU Header is valid, the rest of the PDU may be processed further based on the control information in the PDU Header.
It is to be noted that a PDU may have a separate CRC for the PDU Header and a separate CRC for the actual payload data. The CRC for the PDU Header, i.e., the HCS, only checks the validity of the PDU Header. The CRC for the validity of the payload data in the PDU may be checked separately once the length of the PDU is determined from the PDU Header. The presence of the CRC for the payload data may be negotiated between protocol entities or may be indicated in the PDU Header.
In many scenarios the length of the PDU varies and therefore the length information is generally included in the PDU Header. If the receiver determines that the PDU Header is invalid based on the HCS for a given PDU, the length information in the PDU Header is not usable. Therefore, the receiver may not able to determine the length of the PDU.
When multiple PDUs are concatenated in a single burst as shown in FIG. 5, it is necessary to know the length of each PDU in the burst at the receiver to unpack the individual PDUs in the case where the PDUs are of variable length. Normally, the length of the burst is known to the protocol entity that is processing the burst at the receiver. It is known a priori that the burst starts with a Header of the first PDU in the burst.
The receiver checks the validity of the first PDU Header by verifying its HCS. If the first PDU Header is valid, the receiver can use the length information from the first PDU Header to determine the length of the first PDU and thus determines the beginning of the second PDU in that received burst. Next, the receiver checks the validity of the Header of the second PDU using its HCS. If the second PDU Header is valid, the receiver uses the length field from the second PDU Header to determine the length of the second PDU and thus determines the beginning of the next PDU in that received burst. This continues until all of the PDUs in the received burst are unpacked, as shown in FIG. 7, where the arrows indicate that the process continues to the next PDU after the current PDU is validated, such as by analyzing its HCS.
If the protocol entity at the receiver determines that the. Header of a PDU is invalid, then the length information in the PDU Header is not usable to determine the length of that PDU. If the length of a current PDU is not known, it may not be possible to determine the end of the current PDU. Thus, it may not be possible to determine the beginning of the next PDU that may be present in the received burst of data as shown in FIG. 8. Therefore, the rest of the PDU boundaries in the received burst of data may not be detected by the protocol entity at the receiver.
In this scenario, regardless of the validity of the rest of the PDUs in the received burst of data, the receiver may discard the current and the rest of the PDUs in the received burst of data being processed. This leads to significant loss of data that may have been received successfully at the receiver. This in turn may require some unnecessary retransmissions from upper layer entities which may lead to reduced throughput and waste of bandwidth which is a precious resource in a communication system. In some real-time applications, for example VoIP, the retransmissions may not be useful due to latency issues. This leads to loss of data which may in turn degrade the quality of service.